Do professional software developers write an average of 10 lines of code per day?

Question

In the 1975 software project management book, The Mythical Man Month: Essays on Software Engineering, Fred Brooks states that, no matter the programming language chosen, a professional developer will write an average 10 lines of code (LoC) per day.

Productivities in [the] range of 600-800 debugged instructions per man-year were experienced by control program groups. Productivities in the [range of] 2000-3000 debugged instructions per man-year were achieved by [OS/360] language translator groups. These include planning done by the group, coding component test, system test, and some support activities.

-Page 93 of "The Mythical Man Month" (1975)

The book quotes other numbers too for other projects, saying e.g. that an O/S is more complicated and therefore slower to write than other types of software. However, a 2000 statements/year figure is virtually identical to the often-claimed 10 LoC/day. Further, it is on the nearly same page as the other part of the claim, which is that LoC/day seems independent of the programming language being used.

Productivity [in LoC] seems constant [across languages] in terms of elementary statements [so it's better to use a higher-level language if you can], a conclusion that is reasonable in terms of the thought a statement requires and the errors it may include.¹¹

-Page 94 of "The Mythical Man Month" (1975)

This claim is still being made today (in 2006, at least). From Jeff Atwood's blog, Coding Horror:

Project Size         Lines of code (per year)     COCOMO average
    10,000 LOC           2,000 - 25,000               3,200
   100,000 LOC           1,000 - 20,000               2,600
 1,000,000 LOC             700 - 10,000               2,000
10,000,000 LOC             300 -  5,000               1,600

The COCOMO averages divided across 250 work days per year results in 6.4 to 12.8 LoC/day, encompassing the 10 LoC/day claim from the 1975 book.

Is it true that professional programmers produce code at around 10 LoC/day?

Answer 1

According to Capers Jones, productivity across programming languages is not as constant as the claim, but the evidence supports the claim "it's better to use a higher-level language if you can." As you note in your question, productivity varies dramatically depending on project size, so it's probably not helpful to try to pin down "average LoC / engineer / month" averaged across all different project sizes. But for projects of similar size...

The following tables from "The Economics of Software Quality" show productivity on 10 PBX systems of approximately the same size:

None of the projects were exactly 1,500 function points in size, and the original sizes ranged from about 1,300 to 1,750 function points in size. Here, too, the data normalization feature was used to make all 10 versions identical in factors that would conceal the underlying similarities of the examples. -- Capers Jones; Olivier Bonsignour. The Economics of Software Quality (Kindle Locations 2251-2253). Addison-Wesley Professional. Published 2011.

The data show Lines-of-Code productivity decreasing in higher-level languages (ranging from 480 LoC/Developer-Month with Assembly to 162 LoC/Developer-Month with Smalltalk) but Function Point productivity increasing with higher-level languages (1.92 FP / Developer-Month with Assembly to 7.71 FP / Developer-Month with Smalltalk). This is a chart of the data:

Answer 2

The 2nd edition of Code Complete cites Cusumano et al. (2003) for the best-known (till then) industry figure(s). The paper is based on a survey of 104 projects in four regions of the globe. The authors' LOC/productivity summary is in the table below.

The wide variance does raise an eyebrow, which the authors attribute to different characteristics of the projects in a rather undetailed manner, but they also to posit that

US programmers often have different objectives and development styles. They tend to emphasize shorter or more innovative programs and spend more time optimizing code, which ultimately reduces the number of LOC and increases effort.

There's substantial data on project characteristics in the paper (two tables: one for area/requirements/platform/customer and one for the development practices involved; both tables are a bit large to reproduce here), but the authors did not conduct any regression analysis to test if any of the characteristics explain the variance in a statistically significant way... for this sample (and in this paper). They did do something like that in a companion paper for a smaller/pilot [sub-]sample of 29 US projects:

The regression model was (alas) obtained by stepwise backward procedure. There is obvious multicollinearity going on since the daily builds became explanatory/significant in the final regression but having a functional specification was no longer explanatory.

Also the same (companion) paper on the (29) US projects reported some more detailed descriptive statistics on productivity (mean 26.4 LOC/day, median 17.6):

There's some obvious distribution asymmetry to be inferred from the non-parametric skew here, but the actual sample skewness cannot be calculated just from they summary they reported. Annoyingly, the inclusion of two extra US projects in the first paper mentioned makes it risky to compare the median outputs: 270/17.6 gives us 15.34 working days per month, which probably means a different project was selected as median in the two papers/samples.

---

Some newer data is reported in the DoD Software Factbook v1.1 (sample of 208 projects from 2004 to 2011, but most were from 2008 to 2010)

Their results:

• real-time software 12.2 PM per KESLOC

• engineering software 8.8 PM per KESLOC

• mission support software 5.1 PM per KESLOC

• automated information system 2.8 PM per KESLOC

PM = person month, ESLOC = equivalent source line of code, which is however higher that simply new SLOC, because it also adds modified SLOC, reused SLOC, and auto-generated SLOC, each of these three adjusted with a certain (subunitary) factor. (And 1 KESLOC = 1,000 ESLOC.)

This is based on a log-log regression with the plot below:

The black vertical line in the graph corresponds to an "average" project of 25 KESLOC. This is not a true average even for log-transformed data (which is much closer to normality), but a reasonable approximation (averaging in log-units corresponds to 23,442 ESLOC and the median is 28,840 ESLOC).

Using the mythical 20.8 working days per month, the DoD numbers translate to 3.94 ESLOC/day (RT software) to 17.17 ESLOC/day ("automated information system"), with the in-between figures of 5.46 ESLOC/day for engineering software and 9.42 ESLOC/day for "mission support".

Answer 3

To understand what you're asking, you have to contrast the software situation in 1975 with that of today.

In 1975, you would probably be writing in COBOL on an IBM 360. The input/output situation was very simple: text based displays, printers, and either disc or punch card data sources. Because everyone was writing essentially the same code, the same way, performing very simple tasks, lines of code per day/month/year might have been an applicable measure, although there are still defects and how well the solution addressed the need to consider.

Given the verbosity of COBOL to accomplish even the simplest task, I'd say the 10 lines of code per day sounds low. 10 lines of COBOL code won't even describe one input record.

Today, in 2017, the situation is far more complex. In 1975, most people never got near a computer terminal, and the few that did had a text display connected to a single mainframe. Today, everyone has a computer in their pocket, with a full graphical user interface, connected to the world.

The efficiency of a developer today is more determined by the system and platforms they are using, than how many lines of code they turn out. On a simple level, a web app system like PHP takes far fewer lines of code than a complex web app system like ASP.NET or JSP. Because it's simpler, a developer can produce more lines of code per day. However, as the complexity of the task rises, PHP may not be able to deliver the functionality. It's not efficient if it can't meet the need and your project ends up as a failure.

Unlike 1975, when no one was ever fired for buying IBM, today you can choose a system and platform that looks good by simple metrics, but ends up failing to deliver the functionality needed. Can't be scaled up to meet the need, can't be secured, can't be quickly updated, etc...

Also consider that in 1975, the concept of reusable blocks of code... as in objects and lately web services, didn't exist. There was a lot of duplication of effort back then, that simply doesn't happen today. How may lines of code per day did a developer produce when they reused a known tested web service as a source, rather than rolling that from scratch? Instead of 1000 lines of code, they produced one line of code to call the service, so lines of code per day paints a very misleading picture in that regard.

Lines of code per day might have been applicable in 1975, because everyone was using the same method, performing the same simple tasks. In 2017, the situation is far more diverse, and far more complex. It's like judging a 787 airliner by Wright Flyer metrics, concluding the 787 isn't very good because it it only has one set of wings instead of two.

So to answer your question... it can't be answered because lines of code per day isn't worth establishing in the 2017 computing environment.